1. Field of the Invention
The present invention relates to an apparatus and method for performing a control transfer over a Universal Serial Bus and, in particular, to responding to setup, data, and status transactions of a control transfer.
2. Description of the Related Art
Universal Serial Bus (USB) is a standard peripheral interface for attaching personal computers to a wide variety of devices: e.g., digital telephone lines, monitors, modems, mice, printers, scanners, game controllers, keyboards, and other peripherals. A USB thus replaces existing interfaces such as the RS-232C serial ports, parallel ports, PS/2 interface and game/MIDI ports.
In accordance with USB, all attached devices connect to a personal computer through a single connector type using a tiered-star topology. A host personal computer includes a single USB controller. The host controller provides the interface between the USB network and the host personal computer. The host controller controls all accesses to USB resources and monitors the bus's topology. A USB hub provides USB attachment points for USB devices.
An example of the tiered-star topology of a USB network is shown in FIG. 1. Host PC 100 is a typical personal computer having a USB port connection via host controller 102. Host controller 102 connects directly to root hub 110, which is typically implemented as part of the Host PC 100. Compound device 120, hub 130, and device 140 connect to the host controller 102 through root hub 110. Devices 132 and 134 connect to the host controller 102 through hub 130 and through hub 110.
Compound device 120 includes devices 124, 126 and hub 122. Hub 122 of compound device 120 connects to the host controller through hub 110. Devices 124 and 126 of compound device 120 connect to the host controller 102 through hub 122 and through hub 110. A practical example of a compound device would be an integrated printer and fax. The printer could be device 124, and the fax could be device 126.
The tiered-star topography illustrated in FIG. 1 allows data to be transmitted into and out of the host PC 100 to the various devices. When data is transmitted from the host to a device, it is transmitted downstream through the interconnecting hubs. When data is transmitted from a device to the host, it is transmitted upstream through the interconnecting hubs.
The USB hubs and devices may be connected and disconnected without completely re-starting the USB network. Upon connection of a device or hub to an upstream hub, the upstream hub will notify the host controller of a change in status. Following USB protocol, the host controller will enable the port of the hub to which the device is connected. The host controller will then assign a unique functional address to each device. Ports are enabled one at a time as the host controller 102 assigns unique functional addresses. Upon connection of a compound device, the host controller assigns a unique functional address to each device contained within the compound device. Returning to FIG. 1, devices 124, 126, 132, 134, and 140 along with hubs 110, 122 and 130 will each be assigned a unique functional address upon connection to the USB network.
A USB Function is a USB device that is able to transmit and receive information on the bus. A Function may have one, or more, configurations, each of which defines the interfaces which make up the device. Each interface, in turn, is made up of one of more endpoints.
An endpoint is the ultimate source, or sink, of data. An endpoint pipe provides for the movement of data between the USB and memory, and completes the path between the USB Host and the function endpoint. A USB device may support up to 16 such endpoint pipes at any given time. Each endpoint pipe will have the same functional address.
At initialization of a device, the host controller associates a pipe with the endpoint functions. The pipes allow the host controller to move data into and out of a host memory buffer to and from the endpoints. The USB implements two types of pipe communication modes: stream and message. Stream data does not have a defined USB structure. Message data does have a defined USB structure.
At initialization, a pipe is assigned a claim on USB bus access and bandwidth usage. This assignment will determine priority for transmitting data over a particular pipe to an endpoint. The endpoint's characteristics are also associated with the pipe at initialization. Such characteristics include maximum data payload sizes, directionality of transfers, and other appropriate characteristic data. These characteristics are used by the host in making data transfers over the pipe.
The assignment of a claim on USB bus access and bandwidth to a pipe allows the host controller to make a best effort to ensure that all input/output data requests to endpoints will be adequately serviced over the available bandwidth of the USB bus. The assignment of claims to bus access and bandwidth to a pipe limits the allocation to later configured devices. Once the bandwidth of a USB bus is completely allocated, subsequently configured devices cannot be allocated bus bandwidth. Consequently, the subsequently configured devices cannot be allocated pipes.
After the initialization process completes, the allocation of pipes to particular endpoints of a device is fixed and cannot be changed unless the device is disconnected or reset. Accordingly, devices which include a plurality of endpoint functions will be assigned a plurality of pipes (each associated with a particular endpoint).
Each endpoint is an addressable entity on the USB and is required to respond to IN and OUT tokens from the USB host controller. The IN tokens indicate that the host has requested to receive information from an endpoint; OUT tokens indicate that the host is about to send information to an endpoint.
On detection of an IN token addressed to an endpoint, the endpoint is responsible for responding with a data packet. If the endpoint is currently stalled, a STALL handshake packet is sent. If the endpoint is enabled, but no data is present, a NAK (Negative Acknowledgement) handshake packet is sent.
Similarly, on detection of an OUT token addressed to an endpoint, the endpoint is responsible for receiving a data packet sent by the host and storing it in a buffer. If the endpoint pipe is currently stalled, at the end of data transmission, a STALL handshake packet is sent. If the endpoint pipe is currently disabled, at the end of the data transmission, no handshake packet is sent. If the endpoint pipe is enabled, but no buffer is present in which to store the data, a NAK (Negative Acknowledgement) handshake packet is sent.
A disabled endpoint, or endpoints not currently mapped to an endpoint pipe do not respond to IN, OUT, or SETUP tokens.
The USB defines four types of data transfers over a pipe: control, bulk, interrupt, and isochronous.
Control transfers are used by the host to configure a device upon attachment to a hub. Control transfers may also be used by the host controller for implementation specific transactions with a device.
Bulk transfers are sequential transfers generally of large amounts of data. Bulk transfers provide reliable transactions by use of error detection and re-sending corrupted data. The bus bandwidth allocated for a bulk transfer can be whatever is currently available as bulk transfers are not time sensitive.
Interrupt transfers are small spontaneous data transactions emanating from a device.
Isochronous transfers are continuous, real-time data transactions. Isochronous transfers are allocated a dedicated portion of a USB network's bandwidth to ensure timely completion of isochronous transactions.
The USB specification defines a control transfer protocol for use in configuring, commanding, and checking status of a device. A control transfer is composed of a setup transaction which moves request information from the host to the device, optional data transactions which send data in the direction indicated by the setup transaction, and a status transaction which returns status information from the device to the host. The setup transaction specifies the amount of data to be sent during the data transaction.
The occurrence of an IN or OUT data transaction in the control transaction provides three possible transaction sequences: a control write sequence, a control read sequence, and a control no-data sequence. Each of these will now be described in greater detail.
Turning to FIG. 4A, a control write sequence is shown. The control write sequence includes three stages: a setup stage, a data stage and a status stage. The setup stage consists of a SETUP transaction 410 having a DATA0 PID. The SETUP transaction 410 specifies that an OUT data stage will follow. The data stage consists of an OUT transaction 412 having a DATA1 PID. The OUT transaction 412 is followed by an OUT transaction 414 having a DATA0 PID. This transaction is followed by as many transactions as are required to transmit the necessary data from the host. This will depend both upon the size of the data in the host and the size of the transmitted packets. The DATA PID alternates between 1 and 0 for the OUT transactions used in the data stage. The final OUT transaction 416 ends the data stage. The status stage consists of a single IN transaction 418 having a DATA1 PID.
Turning to FIG. 4B, a control read sequence is shown. The control data IN sequence includes three stages: a setup stage, a data stage and a status stage. The setup stage consists of a SETUP transaction 420 having a DATA0 PID. The SETUP transaction 420 specifies that an IN data stage will follow. The data stage consists of an IN transaction 422 having a DATA1 PID. The IN transaction 422 is followed by an IN transaction 424 having a DATA0 PID. This token is followed by as many transaction as are required to transmit the necessary data from the device. This will depend both upon the size of the data in the device and the size of the transmitted packets The DATA PID alternates between 1 and 0 for the IN transactions used in the data stage. The final IN transaction 426 ends the data stage. The status stage consists of a single OUT transaction 428 having a DATA1 PID.
Turning to FIG. 4C, a control no-data sequence is shown. The control no-data sequence includes two stages: a setup stage and a status stage. The setup stage consists of a SETUP transaction 420 having a DATA0 PID. The status stage consists of a single IN transaction 428 having a DATA1 PID.
A flow chart illustrating a setup transaction is shown in FIG. 3. The transaction begins with SETUP token 310 sent from the host. A setup transaction always includes a DATA0 PID for the data field. The device then responds by sending an ACK handshake to complete the SETUP transaction.
A flow chart illustrating an IN transaction is shown in FIG. 5. The IN transaction begins with an IN token 510 which is sent from the host to the device. The device should then respond with the appropriate DATA packet 512 (either a DATA0 or a DATA1 packet). If, however, the device is temporarily unable to return a DATA packet, it will instead return NAK handshake 514. If the device is unable to return a DATA packet and will require host intervention to recover, it will return a STALL handshake 516. Returning to DATA packet 512, the host will respond with an ACK handshake 518 upon receipt of this packet.
A flow chart illustrating an OUT transaction is shown in FIG. 6. The OUT transaction begins with an OUT token 610 which is sent from the host to the device. The host then sends the appropriate DATA packet 612 (either a DATA0 or a DATA1 packet). If the device receives DATA packet 612 without errors and is ready to receive another packet, it returns ACK handshake 614. If the device receives DATA packet 612 without errors but needs the host to re-send the packet, it returns NAK handshake 616. The NAK handshake is used when a DATA packet's intended endpoint is in a state which temporarily prevents it from receiving the DATA packet. If the device receives the DATA packet 612 but is in a stall condition, it returns a STALL handshake to indicate that the host should not attempt to re-send the packet. If the data packet 612 is received with a CRC or bit stuffing error, no handshake is returned.
The Universal Serial Bus requires that should a connected device receive an unexpected SETUP token, the device must accept the SETUP token.
To accept SETUP tokens and the corresponding DATA0 packet, USB devices dedicate memory for receiving this data. In addition, USB devices allocate memory for receiving tokens for at least one other endpoint. As a USB device may support up to sixteen endpoints, often memory is dedicated to each endpoint for receiving tokens for that endpoint and for sending and receiving data.
Only one endpoint may be active at a time. Accordingly, the memory associated with an inactive endpoint will not be read to transmit data over the Universal Serial Bus. Likewise, the memory associated with an inactive endpoint will not be written to with data from the Universal Serial bus. Nonetheless, each endpoint typically maintains dedicated memory.
Accordingly, a USB device is desired which does not require dedicated memory buffers for each endpoint. Moreover, a USB device is desired which does not require a dedicated memory buffer for a control endpoint but is able to accept unexpected SETUP tokens.